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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document specifies architecture enhancements to facilitate communications with packet data networks and 
apphcations (e.g. Machine Type Communication (MTC) appHcations on the (external) network/MTC servers) as per the 
use cases and service requirements defined in TS 22.368 [2], TS 22.101 [3], and related 3GPP requirements 
specifications. Both roaming and non-roaming scenarios are covered. 

In this release, this document specifies the network elements, interfaces and procedures for: 

Device triggering by applications/servers (e.g. MTC applications on the (external) network/MTC servers) and 
also security mechanisms for device triggering and security for external interfaces. 

PS-Only support with and without MSISDN. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

For a specific reference, subsequent revisions do not apply. 

For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[I] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 

[2] 3GPP TS 22.368: "Service Requirements for Machine-Type Communications (MTC)". 

[3] 3GPP TS 22.101: "Service Aspects; Service Principles". 

[4] 3GPP TS 23.003: "Numbering, addressing and identification". 

[5] 3GPP TS 23.002: "Network architecture". 

[6] 3GPP TS 23.060: "General Packet Radio Service (GPRS); Service description; Stage 2". 

[7] 3GPP TS 23.401 : "General Packet Radio Service (GPRS) enhancements for Evolved Universal 

Terrestrial Radio Access Network (E-UTRAN) access". 

[8] 3GPP TS 29.061: "Interworking between the Public Land Mobile Network (PLMN) supporting 

Packet Based services and Packet Data Networks (PDN)". 

[9] 3GPP TS 29.303: "Domain Name System Procedures; Stage 3". 

[10] 3GPP TS 23.228: "IP Multimedia Subsystem (IMS); Stage 2". 

[II] 3GPP TS 23.272: "Circuit Switched (CS) fallback in Evolved Packet System (EPS); Stage 2". 
[12] 3GPP TS 23.040: "Technical reahzation of the Short Message Service (SMS)". 

[13] 3GPP TS 23.204: "Support of Short Message Service (SMS) over generic 3GPP Internet Protocol 

(IP) access; Stage 2". 

[14] 3GPP TR 23.039: "Interface Protocols for the Connection of Short Message Service Centers 

(SMSCs) to Short Message Entities (SMEs)". 

[15] IETF RFC 3588: "Diameter Base Protocol". 
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[16] IETF RFC 4960: "Stream Control Transmission Protocol". 

[17] WAP-168-ServiceLoad-20010731-a : "Service Loading". 

[ 1 8] OMA-TS-Push MO-Vl 0-201 10809-A : "OMA Push Management Object" . 

[19] OMA-TS-Push Message- V2 2-201 10809-A : "Push Message" . 

[20] OMA-AD-Push-V2 2-201 10809-A : "Push Architecture". 

[21] 3GPP TS 23.221: "Architectural requirements". 

[22] Void. 

[23] 3GPP TS 23.142: "Value-added Services for SMS (VAS4SMS); Interface and signalling flow". 

[24] 3GPP TS 29.368: "Tsp interface protocol between the MTC Interworking Function (MTC-IWF) 

and Service Capability Server (SCS)". 

3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in TR 21.905 [1] apply. 

3.2 Abbreviations 

For the purposes of the present document, the abbreviations given in TR 21.905 [1] and the following apply. An 
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 
TR 21.905 [1]. 

AS Application Server 

CDR Charging Data Record 

CDF Charging Data Function 

CGF Charging Gateway Function 

MTC Machine Type Communications 

MTC-IWF Machine Type Communications-InterWorking Function 

P-GW PDN Gateway 

SCS Services Capability Server 

SLF Subscriber Location Function 

SME Short Message Entities 

SMS-SC Short Message Service-Service Centre 

SRI Send Routing Information 



4 Architecture IVIodel and Concepts 

4.1 General Concept 

The end-to-end communications, between the MTC Application in the UE and the MTC Application in the external 
network, uses services provided by the 3GPP system, and optionally services provided by a Services Capability Server 
(SCS). 

The MTC Application in the external network is typically hosted by an Application Server (AS) and may make use of 
an SCS for additional value added services. The 3GPP system provides transport, subscriber management and other 
communication services including various architectural enhancements motivated by, but not restricted to, MTC (e.g. 
control plane device triggering). 
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Different models are foreseen for machine type of traffic in what relates to the communication between the AS and the 
3GPP system (refer to Annex A) and based on the provider of the SCS. The different architectural models that are 
supported by the Architectural Reference Model in clause 4.2 include the following: 

Direct Model - The AS connects directly to the operator network in order to perform direct user plane 
communications with the UE without the use of any external SCS. The Application in the external network may 
make use of services offered by the 3GPP system; 

Indirect Model - The AS connects indirectly to the operator network through the services of a SCS in order to 
utilize additional value added services for MTC (e.g. control plane device triggering). The SCS is either: 

MTC Service Provider controlled: The SCS is an entity that may include value added services for MTC, 
performing user plane and/or control plane communication with the UE. Tsp is regarded as an inter-domain 
interface for control plane communication; or 

3GPP network operator controlled: The SCS is a mobile operator entity that may include value added 
services for MTC and performs user plane and/or control plane communication with the UE, making Tsp a 
control plane interface internal to the PLMN; 

Hybrid Model: The AS uses the direct model and indirect models simultaneously in order to connect directly to 
the operator's network to perform direct user plane communications with the UE while also using a SCS. From 
the 3GPP network perspective, the direct user plane communication from the AS and any value added control 
plane related communications from the SCS are independent and have no correlation to each other even though 
they may be servicing the same MTC Application hosted by the AS. 

When using the hybrid model, the MTC Service provider controlled SCS, and the 3GPP operator controlled SCS 
may offer different capabilities to the MTC Applications. 

Since the different models are not mutually exclusive, but just complementary, it is possible for a 3GPP operator to 
combine them for different applications. This may include a combination of both MTC Service Provider and 3GPP 
network operator controlled SCSs communicating with the same PLMN. 

4.2 Architectural Reference Model 

Figure 4.2-1 shows the architecture for a UE used for MTC connecting to the 3GPP network (UTRAN, E-UTRAN, 
GERAN, etc.) via the Um/Uu/LTE-Uu interfaces. The architecture covers the various architectural models described in 
clause 4.1. 
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Figure 4.2-1 : 3GPP Architecture for lUlachiine-Type Communication 

NOTE 1: Refer to TS 23.002 [5], TS 23.060 [6], TS 23.401 [7], TS 23.272 [1 1] and TS 23.040 [12] for the details 
of 3GPP network-internal reference points not specifically shown or labelled in figure 4.2-1 or described 
in this specification. 

NOTE 2: The SCS is controlled by the operator of the HPLMN or by a MTC Service Provider. 

NOTE 3: In the non-roaming case, all 3GPP network entities providing functionality for MTC are in the same 
PLMN. In the roaming case, 3GPP architecture for MTC supports both the home routed (illustrated in 
Figure 4.2-1) and the local-breakout roaming (not illustrated) scenarios. For the home routed scenario, the 
MTC Server/ Application User Plane communication is routed through the HPLMN. In the local breakout 
scenario, the User Plane communication is routed directly through the serving PLMN/VPLMN over 
deployed GGSN/P-GW. 

The SCS is an entity which connects to the 3GPP network to communicate with UEs used for MTC and the MTC-IWF 
in the HPLMN. The SCS offers capabilities for use by one or multiple MTC Applications. A UE can host one or 
multiple MTC Applications. The corresponding MTC Applications in the external network are hosted on one or 
multiple ASs. 

Tsms is the interface that encompasses all the various proprietary SMS-SC to SME interface standards (see 
TR 23.039 [14]) and is outside the scope of 3GPP specifications. Tsms can be used to send a trigger to a UE 
encapsulated in a MT-SMS as an over-the-top application by any network entity (e.g. SCS) acting as a SME. Tsp is a 
3GPP standardized interface to facilitate value-added services motivated by MTC (e.g. control plane device triggering) 
and provided by a SCS. 

The API between the MTC Capabilities and mobile operator network services provided by the SCS and the MTC 
Application(s) hosted by the AS(s) are outside the scope of 3GPP specifications and thus, not depicted in the current 
architecture. It is solely used as abstracts to show an example of an end-to-end view for MTC and simplify mapping to 
MTC specifications of other standardization organizations. In the indirect model, MTC Capabilities and the MTC 
Application(s) in the external network can be collocated. 
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For the roaming scenario, the MTC-IWF shall have the connection with HSS and SMS-SC within the home network 
only and with serving SGSN/MME/MSC in the visited network. 



4.3 Reference points 



4.3.1 General 

The following 3GPP reference points support the Indirect and Hybrid models of MTC. 

NOTE: As further development of the MTC architecture takes place as well as when additional MTC common 
functionality and features are addressed, further reference points may be added. 

4.3.2 List of Reference Points 

The description of the MTC related reference points: 

Tsms: Reference point used by an entity outside the 3GPP network to communicate with UEs used for 

MTC via SMS. 
Tsp: Reference point used by a SCS to communicate with the MTC-IWF related control plane 

signalling. 
T4: Reference point used by MTC-IWF to route device trigger to the SMS-SC in the HPLMN. 

T5a: Reference point used between MTC-IWF and serving SGSN. 

T5b: Reference point used between MTC-IWF and serving MME. 

T5c: Reference point used between MTC-IWF and serving MSC. 

S6m: Reference point used by MTC-IWF to interrogate HSS/HLR 

S6n: Reference point used by MTC-AAA to interrogate HSS/HLR 

NOTE 1: Protocol assumption: User plane communication with SCS, for Indirect model, and AS, for Direct and 
Hybrid models, is achieved using protocols over Gi and SGi reference points. Control plane protocols 
over those reference points such as RADIUS/Diameter as specified in TS 29.061 [8] can also be 
supported towards the SCS. 

NOTE 2: In this release of the specification, T5a/b/c reference points are not specified. 

4.3.3 Reference Point Requirements 

4.3.3.1 Tsp Reference Point Requirements 

The Tsp reference point shall fulfil the following requirements: 

connects a MTC-IWF to one or more SCSs; 

supports the following device trigger functionality: 

reception of a device trigger request from SCS; 

report to the SCS the acceptance or non-acceptance of the device trigger request; 

report to the SCS the success or failure of a device trigger delivery; and 

provides congestion/load control information to SCS as part of the response to device trigger requests. 

In addition. Domain Name System procedures similar to what is specified in TS 29.303 [9] may be used by the SCS for 
lookup and selection of which specific MTC-IWF to be used. 

NOTE: Security requirements can be found in clause 4.8. 

4.3.3.2 T4 Reference Point Requirements 

The T4 reference point shall fulfil the following requirements: 
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- connects the MTC-IWF, taking the role of the SME, to SMS-SC inside HPLMN domain; 
supports the following device trigger functionality: 

- transfer of device trigger, addressed by either an MSISDN or the IMSI, from MTC-IWF to SMS-SC inside 
HPLMN domain; 

transfer to the SMS-SC the serving SGSN/MME/MSC identity(ies) along with device trigger when addressed 
by IMSI; and 

report to MTC-IWF the submission outcome of a device trigger and the success or failure of delivering the 
device trigger to the UE. 

4.3.3.3 T5a/T5b/T5c Reference Point Requirements 

The T5a, T5b and T5c reference points shall fulfil the following requirements: 

- T5a connects the MTC-IWF to the serving SGSN; 

- T5b connects the MTC-IWF to the serving MME; 

- T5c connects the MTC-IWF to the serving MSC; 
supports the following device trigger functionality: 

- transfer of device trigger request to the SGSN/MME/MSC; 

report to MTC-IWF the success or failure of delivering a device trigger to the UE; and 

- providing SGSN/MME congestion/load information to the MTC-IWF. 
NOTE: In this Release of the specification, T5a/b/c reference points are not specified. 

4.3.3.4 S6m Reference Point Requirements 

The S6m reference point shall fulfil the following requirements: 

connect the MTC-IWF to HSS/HLR containing subscription and UE related information; and 

- support interrogation of HSS/HLR to: 

- map E. 164 MSISDN or external identifier to IMSI; 

retrieve serving node information for the UE (i.e. serving SGSN/MME/MSC identities); and 

determine if a SCS is allowed to send a device trigger to a particular UE. 

NOTE: It is up to stage3 to define interworking between diameter-based s6m and map-based interface to the 
legacy HLR. 

4.3.3.5 S6n Reference Point Requirements 

The S6n reference point shall fulfil the following requirements: 

support communication between MTC-AAA and HSS/HLR containing subscription and UE related information; 
and 

- support interrogation of HSS/HLR to: 

map between IMSI and External Identifier(s). 
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4.4 Network Elements 

4.4.1 General 

The following 3GPP network elements provide functionality to support the Indirect and Hybrid models of MTC. 

NOTE: As further development of the MTC architecture takes place as well as when additional MTC common 
functionality and features are addressed, further network elements may be defined. 

4.4.2 MTC-IWF 

To support the Indirect and Hybrid models of MTC, one or more instances of an MTC InterWorking Function (MTC- 
IWF) reside in the HPLMN. A MTC-IWF may be a standalone entity or a functional entity of another network element. 
The MTC-IWF hides the internal PLMN topology and relays or translates signaling protocols used over Tsp to invoke 
specific functionality in the PLMN. 

The functionality of the MTC-IWF includes the following: 

termination of the Tsp, S6m and Rf/Ga reference points; 

termination of one or more reference points among T4, T5a, T5b and T5c; 

ability to authorize the SCS before communication establishment with the 3GPP network; 

ability to authorize control plane requests from an SCS; 

the following device trigger functionalities: 

reception of a device trigger request from SCS; 

report to the SCS the acceptance or non-acceptance of the device trigger request; 

report to the SCS the success or failure of a device trigger delivery; 

may apply MTC-IWF and/or SGSN/MME induced congestion/load control as part of the response to trigger 
requests; and 

uses a standardised identifier (e.g. SMS Application Port ID) to allow the UE to distinguish an MT message 
carrying device triggering information from any other type of messages. 

an HSS resolution mechanism for use when multiple and separately addressable HSSs have been deployed by 
the network operator (see e.g. the SLF / Diameter Proxy agent specified in clause 5.8 TS 23.228 [10]); 

interrogation of the appropriate HSS, when needed for device triggering, to: 

- map E. 164 MSISDN or External Identifier to IMSI; 

retrieve serving node information for the UE (e.g. serving SGSN/MME/MSC identifier); and 

determine if a SCS is allowed to send a device trigger to a particular UE. 

selection of the most efficient and effective device trigger delivery mechanism and shielding of this detail from 
SCS based on; 

current UE serving node information from HSS/HLR (e.g. serving MME/SGSN/MSC identifier); 

the device trigger delivery mechanisms supported by the UE; 

the possible device trigger delivery services supported by the HPLMN and, when roaming, VPLMN; 

operator defined device trigger delivery policies, if any; and/or 

optionally, any information received from the SCS. 



£75/ 



3GPP TS 23.682 version 1 1 .2.0 Release 11 13 ETSI TS 1 23 682 V1 1 .2.0 (201 2-1 1 ) 

protocol translation, if necessary, and forwarding towards the relevant network entity (i.e. serving 
SGSN/MME/MSC or SMS-SC inside HPLMN domain) of a device trigger request to match the selected trigger 
delivery mechanism; 

generation of device trigger CDRs with External Identifier and SCS Identifier and forwarding to CDF/CGF over 
instance of Rf/Ga; and 

NOTE 1 : CDR generation with or without a device trigger indication by other network entities is not precluded by 
CDR generation by the MTC-IWF. 

ability for secure communications between the 3GPP network and the SCS. 

The architecture shall allow the use of multiple MTC-IWFs within a HPLMN 

NOTE 2: This is useful in particular to maintain service upon single MTC-IWF failure. 

4.4.3 HSS/HLR 

An HSS/HLR supporting device triggering shall support the following functionalities: 

termination of the S6m reference point where MTC-IWFs connect to the HLR/HSS; 

- stores and provides to MTC-IWF (and optionally to MTC AAA) the mapping/lookup of E. 164 MSISDN or 
external identifier(s) to IMSI and subscription information used by MTC-IWF for device triggering; 

- mapping of E. 164 MSISDN or external identifiers to IMSI; 

optionally, mapping from External Identifiers to MSISDN is also provided for legacy SMS infrastructure not 
supporting MSISDN-less SMS; 

HSS stored "Routing information" including serving node information if available for the UE (e.g. serving 
SGSN/MME/MSC identifier); and 

determine if a SCS is allowed to send a device trigger to a particular UE; 

termination of the S6n reference point; 

provides to MTC-AAA the mapping between IMSI and External Identifier(s). 

4.4.4 GGSN/P-GW 

A GGSN or P-GW supporting the Indirect or Hybrid model of MTC may support the following functionality 

- Based on APN configuration and unavailability of MSISDN and External Identifiers(s) in the GGSN/PGW, the 
GGSN/PGW either queries a MTC AAA server for retrieval of External Identifier(s) based on IMSI or routes 
RADIUS/Diameter requests for AAA servers in external PDNs (as specified in TS 29.061 [8]) via a MTC AAA 
proxy. 

4.4.5 SGSN/MME/MSC 

SGSN and MME specific functionality to support the Indirect and Hybrid models of MTC includes the following: 
SGSN terminates the T5a reference point; 
MME terminates the T5b reference point; 
MSC terminates the T5c reference point; 
receives device trigger from MTC-IWF; 

encapsulates device trigger information in NAS message sent to the UE used for MTC; 
receives device trigger acknowledgement from the triggering UE; 
reports device trigger delivery success/failure status to MTC-IWF; and 
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- may provide SGSN/MME congestion/load information to MTC-IWF. 

NOTE: In this Release of the specification, T5a/b/c reference points are not specified. 

4.4.6 SMS-SC 

SMS-SC specific functionaUty to support the Indirect and Hybrid models of MTC includes the following: 
terminates the T4 reference point where MTC-IWFs connect to the SMS-SC; and 

- supports PS-only MT-SMS that can be dehvered with IMSI in lieu of E. 164 MSISDN; and 
provides the routing information it received from MTC-IWF to SMS-GMSC if needed. 

4.4.7 MTC AAA 

To support translation of the IMSI to External Identifier(s) at the network egress, an AAA function (MTC AAA) is used 
in the HPLMN. The MTC AAA may be deployed to return the External Identifier(s) based on IMSI. Alternatively the 
MTC AAA may be deployed as a RADIUS/Diameter proxy between the GGSN/PGW and the AAA server in the 
external PDN. 

When deployed as an AAA Server, the MTC AAA shall support the following functionalities: 

termination of the S6n reference point where the MTC- AAA communicates with the HLR/HSS; 

return the external identifier(s) corresponding to an IMSI; and 

may query the HSS with IMSI to retrieve the External Identifier(s) and may cache IMSI/External Identifier 
mapping to avoid multiple HSS queries. 

When deployed as an AAA Proxy, the MTC AAA shall support the following functionalities: 

termination of the S6n reference point where the MTC- AAA communicates with the HLR/HSS; 

replace IMSI with an External Identifier for messages to an external AAA server; 

replace External Identifier with IMSI for messages from an external AAA server; 

identifying the destination external AAA server using standard RADIUS/Diameter procedures; and 

optionally, query the HSS with IMSI to retrieve the external identifier(s) and cache IMSI/External Identifier 
mapping to avoid multiple HSS queries. 

4.5 High Level Function 
4.5.1 Device Triggering Function 

Device Triggering is the means by which a SCS sends information to the UE via the 3GPP network to trigger the UE to 
perform application specific actions that include initiating communication with the SCS for the indirect model or an AS 
in the network for the hybrid model. Device Triggering is required when an IP address for the UE is not available or 
reachable by the SCS/AS. 

Device trigger message contains information that allows the network to route the message to the appropriate UE and the 
UE to route the message to the appropriate application. The information destined to the application, along with the 
information to route it, is referred to as the Trigger payload. The UE needs to be able to distinguish an MT message 
carrying device triggering information from any other type of messages. 

NOTE: The Trigger payload, for example, upon the reception by the UE possibly provides information to the 

application that may trigger application related actions. The application in the UE may perform indicated 
actions, such as for example to initiate immediate or later communication to the SCS/AS, based on the 
information contained in the Trigger payload. 
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Device Triggering is subscription based. The subscription provides the information whether a UE is allowed to be 
triggered by a specific SCS. When device triggers are delivered via MT-SMS the serving nodes MME, SGSN and MSC 
provide the service towards a specific UE based on the UE's subscription for MT-SMS and other subscription 
parameters affecting MT-SMS service provision. 

Charging data are collected for the device triggering. The MTC-IWF generates CDRs for the service requester. When 
device triggers are delivered via MT-SMS then network entities, like MME, SGSN, MSC or SMS-SC generate CDRs 
for SMS services provided for the mobile subscriber. 

4.5.2 PS-only Service Provision 

PS-only service provision is providing a UE with all subscribed services via PS domain. PS-only service provision 
implies a subscription that allows only for services exclusively provided by the PS domain, i.e. packet bearer services 
and SMS services. The support of SMS services via PS domain NAS is a network deployment option and may depend 
also on roaming agreements. Therefore, a subscription intended for PS-only service provision may allow also for SMS 
services via CS domain to provide a UE with SMS services in situations when serving node or network don't support 
SMS via PS domain NAS. The functionality that enables PS-only service provision is described in TS 23.060 [6] and 
TS 23.272 [11]. 

The functionality that enables PS-only service provision for SMS delivery in IMS is described in TS 23.204 [13]. 

4.6 Identifiers 

4.6.1 General 

Identifiers relevant for the 3GPP network are specified in TS 23.003 [4]. 

4.6.2 External Identifier 

A subscription used for MTC has one IMSI and may have one or several External Identifier(s) that are stored in the 
HSS. 

NOTE 1 : If several External Identifiers are mapped to one IMSI, some functions might not work in this release of 
the specification. 

External Identifier shall be globally unique. It shall have the following components: 

a. Domain Identifier: identifies a domain that is under the control of a Mobile Network Operator (MNO). The 
Domain Identifier is used to identify where services provided by the operator network can be accessed (e.g. 
MTC-IWF provided services). An operator may use different domain identifiers to provide access to different 
services. 

b. Local Identifier: Identifier used to derive or obtain the IMSI. The Local Identifier shall be unique within the 
applicable domain. It is managed by the Mobile Network Operator. 

NOTE 2: Use of External Identifiers is not restricted to MTC only. 

NOTE 3: Use of IMSI outside the 3GPP operator domain is dependent on the operator policy. 

4.7 Addressing 

For UEs used for Machine-Type Communications (MTC) IP Addressing principles and solutions for different scenarios 
are described in clause 5 of TS 23.221 [21]. 
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4.8 Security Aspects 
4.8.1 Security Requirements 

4.8.1 .1 Requirements on Tsp Reference Point 

The Tsp reference point shall fulfil the following requirements: 

integrity protection, replay protection, confidentiality protection and privacy protection for communication 
between the MTC-IWF and SCS shall be supported: 

mutual authentication between two directly communicating entities in the security domains, in which MTC- 
IWF and SCS respectively reside, shall be supported; 

the use of mutual authentication shall follow the provisions in TS 29.368 [24]; 

integrity protection and replay protection shall be used; 

confidentiality protection should be used; 

privacy shall be provided (e.g. IMSI shall not be sent outside the 3GPP operator domain). 

4.8.1 .2 Requirements on IVITC-IWF 

The functionality of the MTC-IWF includes the following: 

support ability to satisfy security requirements on Tsp reference point in clause 4.8.1.1. 
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5 Functional Description and Information Flow 

5.1 Control and user plane 
5.1.1 Control Plane 



5.1.1.1 
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Legend: 

Diameter: This protocol supports transferring of subscription and UE related information for identifier 
mapping and serving node information retrieval between MTC-IWF and HSS (S6m). Diameter is defined in 
RFC 3588 [15]. 

Stream Control Transmission Protocol (SCTP): This protocol transfers signalling messages. SCTP is 
defined in RFC 4960 [16]. 

Figure 5.1.1.1-1: Control Plane for S6m interface 

NOTE: It is up to stage3 to define interworking between diameter-based s6m and map-based interface to the 
legacy HLR. 
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5.2 Device triggering procedures 
5.2.1 Device triggering procedure over Tsp 
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8. Action in response to Device Trigger 



Figure 5.2.1-1 : Device triggering procedure over Tsp 

1. The SCS determines the need to trigger the device. If the SCS has no contact details for an MTC-IWF, it may 
determine the IP address(es)/port(s) of the MTC-IWF by performing a DNS query using the External Identifier or 
using a locally configured MTC-IWF identifier. 

2. The SCS sends the Device Trigger Request (External Identifier or MSISDN, SCS Identifier, trigger reference 
number, validity period, priority and trigger payload) message to the MTC-IWF. The SCS includes a trigger payload 
that contains the information destined for the MTC application, along with the information to route it to the MTC 
application. 

NOTE 1: The assignment of SCS identifier is out of scope of 3GPP. The SCS identifier should meet the 3GPP / 
operator requirement. As an example it may be possible to use MSISDN as SCS identifier. 

3. The MTC-IWF checks that the SCS is authorised to send trigger requests and that the SCS has not exceeded its 
quota or rate of trigger submission over Tsp. If this check fails the MTC-IWF sends a Device Trigger Confirm 
message with a cause value indicating the reason for the failure condition and the flow stops at this step. Otherwise, 
the flow continues with step 4. 
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4. The MTC-IWF sends a Subscriber Information Request (External Identifier or MSISDN and SCS Identifier) 
message to the HSS/HLR to determine if SCS is authorized to trigger the UE, to resolve the External Identifier or 
MSISDN to IMSI and retrieve the related HSS stored "Routing information" including the identities of the UE's 
serving CN node(s). 

NOTE 2: The MTC-IWF may cache authorization and routing information for the UE. However, this may 

increase the probability of trigger delivery attempt failures when the cached serving node information is 
stale. 

NOTE 3: Optionally, mapping from External Identifiers to MSISDN is also provided for legacy SMS infrastructure 
not supporting MSISDN-less SMS. 

5. The HSS/HLR sends the Subscriber Information Response (IMSI and/or MSISDN and related "Routing 
information" including the serving node(s) identities, cause) message. HSS/HLR policy (possibly dependent on the 
VPLMN ID) may influence which serving node identities are returned. If the cause value indicates the SCS is not 
allowed to send a trigger message to this UE, or there is no valid subscription information, the MTC-IWF sends a 
Device Trigger Confirm message with a cause value indicating the reason for the failure condition and the flow 
stops at this step. Otherwise this flow continues with step 6a. 

6a. The MTC-IWF selects trigger delivery procedure based on the information received from HSS/HLR and local 
policy. If T5 delivery procedure is selected, MTC-IWF attempts T5 trigger delivery procedure. 

NOTE 2: The T5 delivery is not supported in this version of the specification. 

6b. If T5 delivery is unsuccessful or not supported by the serving nodes(s) or by the UE or if T4 delivery is selected 
during step 6a, the MTC-IWF attempts T4 trigger delivery procedure according to clause 5.2.2. Otherwise, this flow 
continues with step 7. 

7. The MTC-IWF sends the Device Trigger Report (External Identifier or MSISDN and trigger reference number) 
message to the SCS with a cause value indicating whether the trigger delivery succeeded or failed and the reason for 
the failure. The MTC-IWF generates the necessary CDR information including the External Identifier or MSISDN 
and SCS Identifier. 

8. In response to the received device trigger, the UE takes specific actions that take into consideration the content of 
the trigger payload. This response typically involves initiation of immediate or later communication with the SCS or 
an AS. 
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5.2.2 Trigger Delivery using T4 
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Figure 5.2.2-1 : T4 Trigger Delivery Flow 

1. The MTC-IWF selects a suitable SMS-SC based on configured information. The MTC -IWF sends a Submit 
Trigger (External Identifier or MSISDN, IMSI, SCS Identifier, trigger reference number, validity period, 
priority, serving node ID(s) if available from HSS, SMS Application port ID, trigger payload) message to the 
SMS-SC. The SMS-SC should avoid an initial HSS/HLR interrogation (SRI for SM) when it has already 
received necessary parameters in the Submit Trigger message from the MTC-IWF. The SMS Application port 
ID is set to address the triggering function in the UE (the SMS Application port ID shall be reserved for trigger 
messages). The SMS-SC does any necessary segmentation for larger messages. 

If "Absent subscriber" was received from HSS, the SMS-SC should not submit the message, but store it directly 
and send a SM Message Delivery Status Report to request the HSS to add the SMS-SC address to the Message 
Waiting List. 

2. The SMS-SC sends a Submit Trigger Confirm message to the MTC-IWF to confirm that the submission of the 
SMS has been accepted by the SMS-SC. 

3. The MTC-IWF sends a Device Trigger Confirm message to the SCS to confirm that the Device Trigger Request 
has been accepted for delivery to the UE. 

4. 5, 6. The short message is delivered to the UE (see MT-SMS procedures specified in TS 23.040 [12]). This may 

involve delivery attempts in MSC, SGSN and/or MME. This may involve delivery attempts over IMS (see MT- 
SMS without MSISDN procedures specified in TS 23.204 [13]). 

The SMS-delivered trigger payload is processed and handled by the triggering function in the UE. Any 
information contained within the trigger payload is forwarded to the related or addressed UE-application. 

7. The SMS-SC generates the necessary CDR information and includes the SCS Identifier. The SMS Application 
port ID which is included in the SM User Data Header is included in the CDRs, i.e. it is possible to perform 
differentiated charging for an SMS used for triggering purposes. The SMS-SC stores the trigger payload, without 
routing information. If the message delivery fails and is attempted to be delivered again, HSS interrogation will 
be performed. 

8. If the message delivery fails, the SMS-SC shall send a SM Message Delivery Status Report to request the HSS to 
add the SMS-SC address to the Message Waiting list. When the message delivery is later re-attempted, a new 
HSS interrogation will be performed. 
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9. The SMS-SC shall always send a Message Delivery Report (cause code, trigger reference number, SCS 
Identifier) to the MTC-IWF. 

5.3 Information Storage 

This clause describes the context information that is stored in the different nodes for MTC device trigger procedure. 

5.3.1 Trigger Information in SMS-SC (Triggering with T4) 

This table includes information that needs to be stored in SMS-SC for triggering with T4. 

Table 5.3.1-1 : SMS-SC trigger information 



Field 


Description 


External Identifier/MSISDN 


It is used to identify the corresponding External Identifiers in the delivery report. 
This can be also the MSISDN if used. 


IMSI 


It is used to indicate the UE used for IVITC that is required to be triggered. 


Trigger reference number 


This is to co-relate the trigger request with trigger response. 


SCS ID 


It is used to allow the SIVIS SC to send the trigger response back to the 
appropriate SCS. 


Trigger payload 


The SIVISC will store the Trigger payload until it receives the delivery 
confirmation. 


Routing Information for SIVIS 


The identities of the serving node{s). 


Priority 


It is used to indicate the priority of trigger request. 


Validity period 


To indicate the time period for which the trigger request is valid. 


SIVIS Application Port ID 


It is used to route the short message to the triggering function in the UE. 



NOTE 1: The Trigger Payload is stored as user data in SMS-SC. 

NOTE 2: Priority, Validity period and SMS Application Port ID are included in the Trigger payload. 

5.4 Security Procedures 

5.4.1 Tsp Interface Security 

The security procedures for the Tsp interface are specified in TS 29.368 [24]. 

5.4.2 Network based solution for filtering SMS-delivered device trigger 
messages 

The following solution may be implemented to filter SMS-delivered device trigger messages. This solution relies on the 
fact that there is a standardised indicator in the SM that can be used to distinguish a trigger SM from other types of SM. 
The solution further assumes that legitimate trigger SMs are delivered via either a SMS-SC in the HPLMN that can 
verify the identity of the SME sending a legitimate trigger SM over Tsms, or via an MTC-IWF in the HPLMN that can 
verify the identity of the SCS sending a legitimate trigger SM over Tsp. 

The HPLMN shall implement Home Network Routing according to TS 23.040 [12] for Mobile Terminated SMs 
destined for all HPLMN subscribers that need protection against unauthorised SMS-delivered device trigger messages 
(e.g. all subscriptions that may be used in MEs that support SMS-delivered device triggering). Home Network Routing 
shall have the effect of forcing the delivery of the SM to an SMS Router in the HPLMN rather than to the serving 
MSC/VLR, SGSN or MME of the destination UE. If an SM received by the SMS Router does not originate from the 
SMS-SC in the HPLMN that handles SMS-delivered device trigger messages, then the SMS Router shall forward the 
SM to infrastructure that shall filter and block all SMs that contain a trigger indication. 

If an SM received by the SMS-SC in the HPLMN that handles SMS-delivered device trigger messages does not 
originate from the T4 interface, then the SMS-SC shall forward the SM to filtering infrastructure. If an SM received by 
the filtering infrastructure contains a trigger indication, and does not originate from a trusted SME that is authorised to 
send trigger SMs, then the SM shall be blocked. If an SM received by the filtering infrastructure contains a trigger 
indication, and does originate from a trusted SME that is authorised to send trigger SMs, then the filtering infrastructure 
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shall only allow trigger requests to be sent to particular UEs that the trusted SME is authorised to send to. It is outside 
the scope of this specification how the filtering infrastructure shall determine if a trusted SME is allowed to send a 
device trigger to a particular UE. 

If a trigger request received by the MTC-IWF originates from the Tsp interface, then the MTC-IWF shall filter and 
block the trigger unless it originates from a trusted SCS that is authorised to send trigger requests. The procedure is 
described in clause 5.2.1 of the present specification. 

NOTE 1 : Depending on operator policy, a trusted source may be authorized to send trigger messages to any UE. 

In order to protect against source spoofing, the interfaces used to transport trigger messages shall be suitably secured. In 
particular, the Tsms, Tsp and T4 interfaces shall be secured. Tsp interface security is specified in clause 4.3.3.1. The 
security mechanisms for the Tsms interface are outside the scope of this specification. 

Filtering of SMS can be performed according to the architecture specified in TS 23. 142 [23]. When the filtering entity 
receives an SM, it can identify if the SM is a trigger SM based on some trigger indication contained in the SM (e.g. port 
address number). 

NOTE 2: In the above solution filtering is distributed between filtering infrastructure associated with the SMS 

Router, filtering infrastructure associated with the SMS-SC, and the filtering functions within the MTC- 
IWF. This reflects the fact that the filtering needs to be invoked by an entity which can verify the source 
of the SM on a locally connected interface. Whilst the SMS Router is in the path of all SMs towards MTC 
devices, it does not have the capability to verify the original source of messages on the Tsp or Tsms 
interfaces, and therefore a solution where only the SMS Router invokes filtering is not sufficient. 

NOTE 3: The solution in this clause aims to protect against unauthorised entities sending potentially high volumes 
of trigger messages to large numbers of MTC devices to cause a Distributed Denial of Service (DDoS) 
attack against the core network. However, the solution only provides protection against SMS application 
level threats; it does not protect against attacks where network internal nodes or network signalling links 
are compromised or abused by an attacker (e.g. spoofing of MAP_Forward_Short_Message operations 
containing trigger indications towards target UEs on an SS7 connection). If such attacks need to be 
mitigated, or if Home Network Routing is not supported by the HPLMN, then the solution specified in 
this clause is not sufficient and some form of end-to-end cryptographic protection of trigger messages is 
needed between the MTC Application in the network and the MTC Application in the UE. Such solutions 
may be provided at an application level outside the scope of 3GPP specifications. A solution to 
cryptographically protect trigger messages may be introduced in a future 3GPP Release. 
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Annex A (Informative): 
MTC Deployment Scenarios 



In the indirect and hybrid models, the deployment of a SCS may be inside or outside the operator domain as illustrated 
in figures A-1 and A-2. When the SCS is part of the operator domain (figure A-1 C and figure A-2), the SCS is 
considered a mobile operator internal network function, is operator controlled, and may provide operator value-added 
services. In this case, security and privacy protection for communication between the MTC-IWF and SCS is optional. 
When the SCS is deployed outside the operator domain (figure A-1 B and A-2), the SCS is MTC Service Provider 
controlled. In this case, security and privacy protection for communication between the MTC-IWF and SCS is needed. 
In the direct model (figure A-1 A), there may not be an external or internal SCS in the communication path. 
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Figure A-1 : Deployment scenarios for direct and indirect model 
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Figure A-2: Deployment scenarios for hybrid model 

An operator may deploy the hybrid model with a combination of no internal and external SCS (as in the Direct Model) 
and internal and/or external SCS (as in the Indirect Model). As shown in Figure A-2, a UE may be in communications 
with multiple SCSs in an HPLMN which can be made up of a combination of operator controlled and MTC service 
provider controlled SCSs. In that scenario, the MTC Service provider controlled SCS, and the 3GPP operator controlled 
SCS may offer different capabilities to the MTC Applications. 

Though not illustrated, it is also possible that the deployment of an AS may be inside the operator domain and under 
operator control. 
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Annex B (Informative): 
Trigger Delivery using T5 



NOTE: T5 triggering is work in progress and not part of this Release. 
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Figure B-1 : T5 Trigger Delivery Flow 

L The MTC-IWF uses the UE capabilities, serving CN node(s) capabilities retrieved from the HSS to select a 
suitable serving CN node capable of T5 triggering. The MTC-IWF sends a Submit Request (IMSI, message 
priority, MTC-IWF ID, reference number, single delivery attempt flag (optional), validity time (optional). 
Request type (trigger application), application PDU) to the serving CN node. If there is more than one serving 
CN node, the MTC-IWF should send the message to the serving CN node where the UE is currently camping 
with highest probability e.g. based on information received from HSS or cached information from earlier trigger 
attempts. 

2. The serving CN node indicates the Request type (trigger application), application PDU, MTC-IWF ID, 
Reference number within the NAS message and delivers it to the UE. Serving CN node generates the necessary 
CDR information for charging. UE provides the trigger content and trigger type to the corresponding application. 

Editor's Note: It is FFS whether and how a generic container or SMS can be used to transport the trigger content. 

NOTE: If the UE is in idle mode, the serving CN node may page the UE prior to sending a NAS message for 
delivering the trigger. 

The UE responds with the delivery status (cause), MTC-IWF ID, Reference number. Response type (trigger 
application), and optionally, application PDU. 

3. The serving CN node sends a Delivery Report (IMSI, cause, reference number, delivered by CN node. Response 
type (trigger application), and if received, application PDU) message to the MTC-IWF. Cause indicates whether 
the Trigger-Message was successfully delivered to the UE or if failed, the reason for the failure. 



ETSI 



3GPP TS 23.682 version 11.2.0 Release 11 



26 



ETSI TS 123 682 V1 1.2.0 (2012-11) 



Annex C (Informative): 
Triggering with OIVIA Push 

C.1 General 

The 3GPP Device Trigger function enables a transport of application defined triggers to be delivered from a Service 
Capability Server (SCS) towards the UE. One defined application trigger framework is OMA Push Architecture [20]. 
OMA Push defined messages can be carried as payload in the Device Trigger message. 



C.2 Triggering flow using Service Loading 
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Figure C.2-1 : Triggering flow using OMA Push 

1. The SCS generates content (e.g. an MTC application specific command) and a URI towards the content (or 
receives a URI towards content from another source) and then the SCS (performing OMA Push Proxy Gateway 
functionality) generates a Push Message [19] with the PDU set according to Service Loading [17], and sends a 
trigger request over Tsp according to clause 5.2.1. 

2. The MTC-IWF receives the trigger request and sends it according to clause 5.2.1. 

3. The UE SMS dispatcher receives the SMS and routes it to the OMA Push Client which has registered for the 
triggering routing identifier (e.g. SMS Application port). The OMA Push Client, optionally validates the source 
(using white-list defined in OMA Push Management Object [18]) and then forwards the trigger using the 
Application-Id (e.g. to the M2M Service Capability Layer). 

4. The UE activates a PDP/PDN connection. 
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5. The content described as part of the URI is retrieved (retrieval of content is mandatory for content type Service 
Loading [17]). 

6. Based on the content retrieved the addressed Application may perform additional actions (e.g. the M2M Service 
Capability Layer may convey the information to an M2M Application addressed as part of the "command" 
retrieved, within the same or in a different physical device), but this is outside scope of 3GPP standardisation. 
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Annex D (Informative): 

Device triggering using direct model over user plane 

The following flow shows an example of device triggering using direct model over user plane. In this example, an 
application in the UE explicitly registers with a DT-AS/SCS (Device Trigger Application Server) in the home operator's 
network using an existing PDN connection (e.g., default PDN connection). The DT-AS uses the information from the 
application registration (such as IP address, port, protocol, etc.) to deliver the incoming device triggers, forwarded by 
another AS (e.g., third party AS) or itself, to the UE through the user plane. Once the UE receives the trigger, the UE 
either uses the existing PDN connection or the UE sets up a new PDN connection to the appropriate APN to contact the 
third-party Application Server. 
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the appropriate AS 



Figure D-1 : Triggering flow using direct model over user plane 

1 . The UE/MTC application registers with the DT-AS in an operator's network using an existing PDN connection 
(for e.g., default PDN). The registration information, for example, could include the IPv4/IPv6 address and the 
port number where the application is reachable. 

2. The DT-AS receives a trigger from a third-party AS to reach the UE. 

3. The DT-AS delivers the trigger to the UE over the user plane. 

4. The UE either uses the existing PDN connection or sets up a new PDN connection using the appropriate APN to 
contact the third-party AS. 
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